home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940141.txt < prev    next >
Internet Message Format  |  1994-11-13  |  32KB

  1. Date: Thu,  7 Jul 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #141
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu,  7 Jul 94       Volume 94 : Issue  141
  11.  
  12. Today's Topics:
  13.                             Amateur Radio
  14.                           AX.25 PBBSs vs NOS
  15.                              DOS (3 msgs)
  16.                  Index to the tcp-group mail archives
  17.                                LPD help
  18.                          PE1CHL Source Code?
  19.                       TCP-Group Digest V94 #140
  20.                Why not a solid PBBS prog .. or Net.TV ?
  21.  
  22. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  23. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  24. Problems you can't solve otherwise to brian@ucsd.edu.
  25.  
  26. Archives of past issues of the TCP-Group Digest are available
  27. (by FTP only) from UCSD.Edu in directory "mailarchives".
  28.  
  29. We trust that readers are intelligent enough to realize that all text
  30. herein consists of personal comments and does not represent the official
  31. policies or positions of any party.  Your mileage may vary.  So there.
  32. ----------------------------------------------------------------------
  33.  
  34. Date: Thu, 07 Jul 94 11:26:45 GMT-1
  35. From: 86CS/SCMPA <cgscmpa@86wg.ram.af.mil>
  36. Subject: Amateur Radio
  37. To: TCP-GROUP@ucsd.edu
  38.  
  39.      
  40.      My name is Eddie Coates, and I subscribed to the TCP-Digest in hopes 
  41.      of gaining more knowledge of packet radio.  However, being that I am 
  42.      extremely new to the hobby, everything that I've read is way over my 
  43.      head.  Could you reccomend a mailing list or two that might be aimed 
  44.      at the novice end of things.  I would be grateful for any help.
  45.      
  46.      Also, I run an Amiga 500 and am interested in running packet radio 
  47.      with it.  Can you push me in the right direction.
  48.      
  49.      Thanx in advance 
  50.      Eddie  KB8FZQ
  51.  
  52. ------------------------------
  53.  
  54. Date: Wed, 06 Jul 94 14:06:00 EDT
  55. From: "Battles, Brian" <bbattles@arrl.org>
  56. Subject: AX.25 PBBSs vs NOS
  57. To: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  58.  
  59. WARNING: THIS IS A HUGE MESSAGE!  8-)
  60.  
  61. (I accidentally left my Verbose parameter on!)
  62.  
  63. =========BEGIN QUOTED MATTER=======================================
  64.  
  65. Date: Fri, 1 Jul 1994 08:08:35 -0500 (CDT)
  66. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  67. Subject: Stinkin' PBBS
  68.  
  69. bbattles@arrl.org writes about what dgregor@bronze.coil.com writes:
  70.  
  71. >> I've been thinking of something like this. If everyone could get together 
  72.  
  73. >> and write a good Amateur Radio PBBS program for Linux
  74.  
  75. > why isn't there a good, solid, NOS-based PBBS package available for hams 
  76. who
  77. > run DOS, Windows or OS/2 machines?
  78.  
  79. Gary L. Grebus writes:
  80. > "Stamp out the PBBS in our lifetime."
  81.  
  82. Gary speaks pretty much the opinion of most people that have been around 
  83. packet radio for any length of time. If you really want to bore someone to 
  84. death, have them buy a TNC and log into a PBBS for 10 days; then call the 
  85. coroners office for a pickup. It's not something that gets better with age. 
  86. Just like the bulletin board in the lobby of schools and offices, nobody 
  87. ever reads it, but a lot of people stick things on it.
  88.  
  89. Probably the only intelligent thing I've read on the subject of transfering 
  90. information has to do with broadcast protocols.  For example, it seems 
  91. criminal that a PBBS would hand deliver copies to a circle of machines on 
  92. the same frequency (eg, a satellite, or a town PBBS) when it could just 
  93. broadcast the information while the others listened. The other really 
  94. interesting article is "The HUB 5/29 IP Routing Experiment" in the 12th ARRL 
  95. Digital Conference. Read this, and then decide whether you're still 
  96. interested in a boring PBBS. Paul Overton and Ian Wade discuss a really nice 
  97. routing scheme (only a mobile user would complain I suspect--but TCP/IP 
  98. isn't ready for mobile/portable anyway) and then goes on to explain their 
  99. modifications to NNTP that takes advantage of this. We've seen several 
  100. automated IP routing schemes proposed, but the truth is that ham networks 
  101. don't need them. If you have more than 3 entries in your routing table, you 
  102. should read this article. I'd like to read more about this system and maybe 
  103. see a distribution for others to duplicate.
  104.  
  105. Basically I see no advantage of prolonging the PBBS given an operating 
  106. network. The lack of a network is the reason the PBBS exists today. I think 
  107. if towns or communities developed along the lines of the HUB 5/29 article it 
  108. would make for a simple (easily duplicated) network scheme that could 
  109. transport more substantial mail or news articles. I know this will never 
  110. happen in Oklahoma because there's no organization, but other communities 
  111. should look into this network and abandon the stupid PBBS, Rose and Netrom.
  112.  
  113. Steve
  114.  ------------------------------
  115. Date: Fri, 01 Jul 94 15:55:24
  116. From: kz1f@RELAY.HDN.LEGENT.COM
  117. Subject: Stinkin PBBS
  118.  
  119. > Gary speaks pretty much the opinion of most people that have been around
  120. > packet radio for any length of time. If you really want to bore someone
  121. > to death, have them buy a TNC and log into a PBBS for 10 days; then call
  122. > the coroners office for a pickup. It's not something that gets better
  123. > with age.
  124.  
  125. I couldn't agree more. However I think the real problem is the bulk of the 
  126. PBBS users are running DOS (or maybe even Windoze) and use a terminal 
  127. emulator or (terminal.exe) to log into their favorite PBBS. The machines are 
  128. probably 286's and the memory is 640k. To answer Brian's question, the folks 
  129. writing the 'really slick new" software aren't running 286s with 640k and 
  130. given its such an labor of love  to write this stuff they generally write it 
  131. with the understanding that they too will use it. If I'm reading the 
  132. sentiment right, one won't find any more DOS based xNOS's. There'll be char 
  133. based Lunix or graphically based OS/2 or maybe even Windoze-based versions 
  134. of TCP/IP suites that may not even support AX.25 mailboxes nor netrom....I 
  135. know mine won't.
  136.  
  137. Walt
  138.  ------------------------------
  139. Date: Fri, 1 Jul 1994 18:56:55 -0700
  140. From: Phil Karn <karn@qualcomm.com>
  141. Subject: Why not a solid PBBS program?
  142. To: bbattles@arrl.org
  143.  
  144. >  Perhaps it would take a commercial venture to do it right. Would a PBBS
  145. >SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas,
  146. >PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats
  147. >the heck out of the standard freebie AX.25 PBBS packages or the bazillion
  148. >semi-complete NOSs floating around?
  149.  
  150. Why do we have to have PBBSs at all, especially if we're using TCP/IP? Why 
  151. do hams have to keep reinventing the wheel, especially ones that aren't 
  152. quite round? What's wrong with just using all the mail and news software 
  153. that the rest of the Internet uses that seems to work fine for them? Why do 
  154. hams always have to be different?
  155.  
  156. Phil
  157.  
  158. ===============END OF QUOTED MATTER========================================
  159.  
  160. I must say that I agree, in principle. Your everyday local DOS-based AX.25 
  161. PBBS is a neat resource that's become an anachronism with so many more 
  162. advanced choices today. The simple problem is that the hundreds of PBBS 
  163. SysOps and thousands of PBBS users aren't likely to drop everything and 
  164. tackle that infamous "NOS learning curve" after they've just (in many cases) 
  165. gotten close to mastering MSYS, W0RLI, FBBS, etc.
  166.  
  167. We have to face it, in 1994, at least, your average amateur packet radio 
  168. operator still sees TCP/IP as an "experimental" mode. But most packet ops 
  169. have come to rely on packet (PBBS or DX cluster) as a service not unlike the 
  170. telephone company. It's more a utility to them than a real "ham radio" mode. 
  171. Thousands of radio amateurs operate their TNCs with dumb terminals, and 
  172. they're satisfied. People who want file transfers rely on their cheap 14,400 
  173. bit/s telephone modems. Unsatisfactory experience with digipeaters and nodes 
  174. has left many hams cold and uninterested in packet anymore, and unwilling 
  175. even to try out TCP/IP.
  176.  
  177.   I know it's difficult for people like us to imagine, but I know young 
  178. (teens through 30s), enthusiastic new hams who don't have the vaguest guess 
  179. at what a DOS is or how to turn on a PC. Many of them, however, always hear 
  180. all about packet from ham friends and are interested in getting started. 
  181. Taking someone who doesn't even know the difference between an RS-232 
  182. connector and an ac cord and trying to describe how to operate a plain AX.25 
  183. TNC is a challenge; teaching them what TCP/IP is and how to use might well 
  184. be a full-time job!
  185.  
  186.   There always have been and always will be amateurs with widely differing 
  187. levels of knowledge, interest and experience. A few of us are comfortable 
  188. with TCP/IP, HF DXing, contesting, ragchewing on repeaters, playing with 
  189. RTTY, AMTOR, PacTOR and satellites, pointing ATV cameras at each other, 
  190. running coommunity service communication activities, and piddling around 
  191. with simple kits. Others use their licenses solely to experiment with 
  192. VHF/UHF packet. The AX.25 PBBS network is a simple, 
  193. "lowest-common-denominator" system for sending mail and ragchewing via 
  194. keyboard (as mail or in real time). Personally, I feel that it would be far 
  195. more efficient and productive to essentially let all the AX.25 PBBSs fade 
  196. away to be supplanted by a national (worldwide?) network of TCP/IP users and 
  197. Switches (ideally, all running *at least* 9600 bauds), with all sorts of 
  198. useful, interesting Servers, Internet wormholes and gateways, and links to 
  199. HF (ALE, Clover, G-TOR, whatever).
  200.  
  201.   Is this going to happen? Perhaps. Soon? No. Until TNCs come with built-in 
  202. TCP/IP software and a friendly (GUI?) interface, learning to set MYCALL and 
  203. TXDELAY, how to switch from cmd: to converse mode, and how to connect to a 
  204. PBBS and list/read SALE@USBBS bulletins or DX spots is enough for most 
  205. amateurs who own packet equipment. That is real life, outside these 
  206. conferences and newsgroups.
  207.  
  208.   What's my point? Simply that AX.25 PBBSs are here to stay (for now) and 
  209. the only way to get the main body of the packet population interested in 
  210. TCP/IP and other advanced modes is to coexist with AX.25 PBBSs. This means 
  211. gatewaying mail between AX.25 and SMTP, offering Telnet to users who enter 
  212. the TCP/IP system via plain AX.25 connects, providing Convers servers (and 
  213. other "goodies"), and perhaps even (shudder) inventing a truly efficient 
  214. method to operate a DX cluster on a NOS-based station in a way that's better 
  215. than AK1A's PacketCluster. All those SALE, WANTED, HELP, HUMOR, NASA, KEPS, 
  216. AMSAT, ARL, DX, FEST, EXAMS, MODS, etc, bulletins have to be available to 
  217. someone who dumps his PBBSing habit and commits a PC, radio, TNC and a bunch 
  218. of hours of learning and tweaking to operating NOS.
  219.  
  220.   Why convert more packet operators from AX.25 to TCP/IP? Because every 
  221. station running NOS can act as a link or even a Switch, if they're in an 
  222. advantageous location and there's a need. There's no major functional 
  223. distinction between one NOS user and another, as there is between a user and 
  224. a PBBS in the "plain-AX.25" world. Very broadly speaking, more TCP/IPers 
  225. means more service and connectivity, whereas more AX.25 users means more 
  226. congestion and less efficiency. When it comes to TCP/IP (again, very 
  227. generally speaking), the more users, the better. Not to mention that larger 
  228. local groups means more people potentially willing and able to pool 
  229. resources to invest in central LAN Switches with duplex repeaters and 
  230. dedicated Switch-to-Switch links.
  231.  
  232.   There's no need to "dilute" NOS or try to mash in enough code to turn it 
  233. into a completely "dual-personality" AX.25 PBBS and TCP/IP combo-in-a-box. 
  234. But it would be useful to see a reasonably smooth (I hate the word 
  235. "seamless") system for intermingling as much of the two flavors of packet as 
  236. possible, at least until TCP/IP users clearly outnumber AX.25 packeteers.
  237.  
  238.               ==========================================
  239.  
  240.    Say, here's a rare opportunity: I "guest wrote" what's planned to be the 
  241. Packet Perspective column in September '94 QST. Here's my first draft...have 
  242. a gander at it (especially the last paragraph) and shoot me e-mail if you 
  243. have any substantial, specific points you want o clarify, correct or submit 
  244. an opinion about. No guarantees about whether I'll use it, or even that my 
  245. final draft will look much like this, but I'd like to see how you as an 
  246. informed packet operator feel about this:
  247.  
  248.  
  249. Packet Perspective
  250.  
  251.  
  252. @USBBS
  253.  
  254. Anyone who has visited the Never Land of written electronic
  255. communication knows that the open forum provided by telephone
  256. bulletin boards (BBSs), the Internet and other similar media have
  257. long offered users exciting, effective means of discussing,
  258. debating and announcing diverse opinions, issues and emotions.
  259. These environments have traditionally relied on two basic means
  260. of controlling the content of messages posted and behavior of
  261. those who choose to participate: (1) a "gatekeeper" and (2) peer
  262. pressure. The gatekeeper (SysOp) can decide who may post
  263. material, what may be posted and if it will be forwarded. Peer
  264. pressure, the most visible yet least powerful, provides a vocal,
  265. but ultimately impotent form of obligation to conformity. It does
  266. this through friendly advice, admonishment, chastisement and
  267. outright insult. In amateur packet radio, a third entity wields a
  268. measure of control: The regulator (the FCC), which determines
  269. what is legally acceptable.
  270.  
  271. Traditional wired networks, such as the seminal Fidonet, maintain
  272. an accepted level of decorum through a time-honored voluntary
  273. standard of cooperation and a well-defined hierarchy of people
  274. who have definite levels of enforcement authority. Specific
  275. areas, also known as "conferences" or "forums" (or Echoes, in the
  276. case of Fidonet), are designated where users may write messages
  277. pertaining to that area's usually narrowly defined topic. A
  278. volunteer, often selected by conference participants, acts as
  279. moderator. This person's job is to regularly post a set of
  280. conference rules, to monitor the posted messages and to point out
  281. transgressions. Theoretically, the moderator's presence is to
  282. serve as a referee, to inform users of transgressions and to
  283. reduce the amount of peer-to-peer bickering among users over each
  284. others' perceived misbehavior. Users who repeatedly violate the
  285. rules after sufficient warnings from the moderator are reported
  286. to the SysOp of the site where the user logs in to post messages,
  287. who provides the offending user access to the conference. It
  288. becomes the SysOp's responsibility to counsel, rehabilitate,
  289. educate or bar the user's access to the conference. The SysOp is
  290. motivated by the potential consequence of having his BBS
  291. excommunicated from the network if he fails to exercise the
  292. proper control over his users' behavior.
  293.  
  294. In the world of amateur packet radio bulletin boards (PBBSs),
  295. however, there are differences that make control and adherence to
  296. standards difficult to implement. For one thing, open packet
  297. bulletin traffic isn't carried and categorized in distinctly
  298. separate "conferences" that a user may conveniently choose to
  299. read or ignore by simply selecting from a menu. All packet
  300. bulletins are mixed into a homogenous list that users see
  301. whwnever they log in and request a listing of the day's latest
  302. mail. Second, the spirit of democratic, uncensored participation
  303. that offers many advantages to radio amateurs precludes most
  304. SysOps from refusing access to uncooperative users, and even
  305. pressures them to make undesirable messages available to all of
  306. their local users, and even to forward such messages to other
  307. PBBSs in the network. SysOps have been roundly and publicly
  308. criticized for refusing to forward bulletins they deemed to be
  309. inappropriate, even if only for purely technical reasons. In many
  310. raging discussions, users have maintained that a SysOp is
  311. obligated to accept and forward their message without question,
  312. as long as it doesn't expressly violate any FCC rules. (This is,
  313. by the way, entirely untrue. According to the law, no SysOp is
  314. under any obligation to do anything whatsoever with any radio
  315. amateur's messages, and the law also states that a PBBS is its
  316. SysOp's privately operated radio station, for which the SysOp is
  317. permitted--in fact, expected--to monitor and control the material
  318. it transmits.)
  319.  
  320.  
  321. Educating Users
  322.  
  323. To turn to a more basic, pragmatic issue, many packet operators
  324. have spent many hours discussing the frustration of having these
  325. PBBS, supposedly design and built for the main purpose of
  326. carrying person-to-person mail traffic and occasional bulletins
  327. of general interest, into electronic "classified ad pages."
  328. Notices that carry announcements of items for sale, swap or
  329. wanted, noticeably far outnumber every other single type of
  330. bulletin. Because of its convenience, low cost and apparent
  331. effectiveness, PBBS users indundate the airwaves with a
  332. nationwide swapfest day and night. Most messages in this category
  333. are individually harmless, but when viewed as a class, are the
  334. greatest consumers or computer storage space, message-forwarding
  335. time and bandwidth.
  336.  
  337. Many SysOps, and more PBBS users, complain that all you ever see
  338. listed on a PBBS today are screenfuls of "SALE@USBBS" messages
  339. and so on. It's an understandable lament: There's a lot of stuff
  340. in there, but most of it is "junk mail" most users will never
  341. read. For example, a ham in Boston isn't likely to care about a
  342. personal computer or hand-held transceiver being sold by an
  343. amateur in Seattle. But there are hundreds, perhaps thousands of
  344. amateurs in Washington or perhaps the Pacific Northwest region
  345. who will read and respond to such a notice. So why waste the time
  346. and bandwidth to send this bulletin ping-ponging all over the US
  347. by adressing it so it's forwared to "@USBBS"?
  348.  
  349. In a sadly ironic way, most packet messages posted aren't nearly
  350. as efficient as the non-SysOp packet operator believes. It's
  351. common to see items too insignificant or unwieldy to be easily
  352. sold to amateurs hundreds of miles away sent out addressed to
  353. "FOR SALE @ USBBS," a lazy, or perhaps misunderstood format that
  354. causes thousands of amateurs in Alabama, for example, to have
  355. their local PBBSs spew forth several screens full of listings for
  356. hand-held transceivers, parts, batteries and other such items
  357. that are being offered by hams in Oregon or Alaska, and that are
  358. likely to be sold by the time they reach most out-of-state PBBSs.
  359.  
  360.  
  361. SysOps: Can You Do It?
  362.  
  363. Perhaps there needs to be a system implemented by which SysOps
  364. would be asked to voluntarily help educate users by requiring the
  365. user to read an educational message about the most appropriate
  366. way to address bulletins before the user would be given the
  367. privilege of posting a message that was intended to be forwarded
  368. to other PBBSs. This would require at least two things: (1) The
  369. PBBS software would have to support a method of doing so, and (2)
  370. The SysOp would have to be willing to invest whatever additional
  371. time it might take to grant access to potential users who
  372. acknowledge that they've read and understand the proper
  373. procedure.
  374.  
  375. Is it reasonable to suggest that PBBS SysOps route incoming
  376. messages addressed to @USBBS" to some kind of holding bin, unless
  377. they meet certain criteria (eg, ARL, KEPS, AMSAT, FCC, SYSOP, DX,
  378. etc)? For example, do we really need so many SALE, WANTED, HELP,
  379. FEST and EXAM bulletins addressed to, and circulated over the
  380. airwaves to, @USBBS? Does it offer any real advantage to the user
  381. who posts it? Isn't it more efficient, timely and appropriate to
  382. post most bulletins to a local, state or regional circulation?
  383. Could PBBS SysOps do this, and would they want to? How much extra
  384. time and effort would it take? Can any of this be automated? Will
  385. an investment in the time and energy now pay off later with less
  386. "junk mail" coming through each PBBS in the near future, if users
  387. can be taught to cut down the unnecessary "@USBBS" traffic?And
  388. how much actual improvement would that offer all amateurs,
  389. regarding the possible decrease in traffic transmitted via
  390. VHF/UHF backbone and HF forwarding?
  391.  
  392. This could certainly be implemented in a friendly manner, with
  393. errant users gently instructed in a friendly, helpful manner.
  394. Each PBBS SysOp could prepare a "boilerplate" text he could use
  395. to inform a user whose postings were held or rerouted that would
  396. explain what was done, why it was done and how to avoid such faux
  397. pas in the future. A standard one-page (one screen?) message from
  398. the SysOp could simply inform the user that @USBBS is, by
  399. conventional agreement, reserved for messages that, by their
  400. inherent nature, lend themselves most advantageously to
  401. distribution to the entire nation's amateurs. It could advise the
  402. user that buying, selling, swapping or evaluating almost any
  403. Amateur Radio item could be quite effectively accomplished via a
  404. local or regional bulletin, and that he should seriously consider
  405. if the hams in a distant state will care or be able to take
  406. advantage of the information in certain types of messages.
  407.  
  408.  
  409. The Alternative
  410.  
  411. This primarily concerns standard AX.25 PBBS users and SysOps
  412. because more advanced software, such as that used for TCP/IP
  413. networking, doesn't even involve PBBSs, as most hams know them. A
  414. TCP/IP user finds his mail forwarded neatly stored in his own
  415. private mail area on his own computer's disk drive. Bulletins can
  416. be forwarded only to TCP/IP operators who specifically request
  417. them, by category, from stations that act as "gateways" to
  418. collect useful bulletins from local AX.25 PBBSs and mail them
  419. directly to those who want to see them. Ideally, if all US packet
  420. stations operated TCP/IP software, rather than standard, "built-
  421. in" AX.25, the traditional PBBS could be eliminated and amateur
  422. packet radio would function more like the Internet. Each station
  423. would be accessible directly by every other station, and each
  424. amateur could choose to "subscribe" to "newsgroups" that
  425. encompass particular topics.
  426.  
  427. Let's hear what you think, as a packet operator, and especially
  428. as a PBBS SysOp. Poke holes in my suggestion or offer ideas on
  429. how to improve it. Be constructive and thoughful, and perhaps
  430. we'll be able to slowly educate our fellow packet operators so
  431. that we can all help each other maintain, expand and speed up our
  432. powerful, impressive amateur packet radio network.
  433.  
  434.  
  435.  
  436. CUL es 73 de BB
  437.  ___________________________________________________________________________
  438.  Brian Battles, WS1O  I  Internet     bbattles@arrl.org  I  "Radio amateurs
  439.  QST Features Editor  I  Compu$erve   70007,3373         I   do it with high
  440.  ARRL HQ              I  MCI Mail     215-5052           I      frequency"
  441.  Newington, CT USA    I
  442.  Tel 203-666-1541     I  Amprnet      ws1o@ws1o-2.ampr.org [44.88.2.43]
  443.  Fax 203-665-7531     I  AX.25 packet WS1O @ W1EDH.CT.USA.NA
  444.  BBS 203-666-0578
  445.  ___________________________________________________________________________
  446.       COMMENTS EXPRESSED HEREIN ARE MY OWN PRIVATE, PERSONAL REMARKS
  447.      AND ARE TOO INANE TO BE CONSIDERED OFFICIAL ARRL VIEWS OR POLICY.
  448.  
  449. ------------------------------
  450.  
  451. Date: Wed, 06 Jul 94 16:00:05      
  452. From: kz1f@RELAY.HDN.LEGENT.COM
  453. Subject: DOS
  454. To: "TCP digest" <tcp-group@ucsd.edu>
  455.  
  456. I must add my two cents in here. I understand the sentiment behind 
  457. bad-mouthing DOS (its so easy to do). But I dont understand the mad rush to 
  458. replace it with a version of Unix, free or otherwise. In this day and age 
  459. its a real labor of love to learn the Unix cmds and associated flags.
  460. It may have one advantage though, one doesnt need to write a xNOS to run
  461. onit, merely write the appropriate driver for the tnc or PI card. But I 
  462. can't imagiine there are that many folks interested in learning how to write
  463. device drivers, for DOS, OS/2 or Unix. 
  464. Am I missing something here?
  465. Walt kz1f@relay.hdn.legent.com
  466.  
  467. ------------------------------
  468.  
  469. Date: Wed, 6 Jul 1994 16:22:25 -0700 (PDT)
  470. From: Lyndon Nerenberg <lyndon@unbc.edu>
  471. Subject: DOS
  472. To: kz1f@RELAY.HDN.LEGENT.COM
  473.  
  474. On Wed, 6 Jul 1994 kz1f@RELAY.HDN.LEGENT.COM wrote:
  475.  
  476. > I must add my two cents in here. I understand the sentiment behind 
  477. > bad-mouthing DOS (its so easy to do). But I dont understand the mad rush to 
  478. > replace it with a version of Unix, free or otherwise. In this day and age 
  479. > its a real labor of love to learn the Unix cmds and associated flags.
  480.  
  481. Can you say client/server boys and girls? I *knew* you could :-)
  482.  
  483. Use the Unix box as the news/mail/convers server. Let the end users run 
  484. Windows based clients talking IP over the radio. Everyone gets to use 
  485. their favorite software and nobody has to learn to type 'man'.
  486.  
  487. The scary thing is that *all* the application software has already been 
  488. written. All that's missing is a packet driver that knows how to talk to 
  489. a TNC and fake out AX25 callsign/SSID MAC addresses as if they were 
  490. Ethernet MAC addresses.
  491.  
  492. --lyndon
  493.  
  494. ------------------------------
  495.  
  496. Date: Thu, 07 Jul 1994 12:50:42 +1000
  497. From: ccdrw@cc.newcastle.edu.au (Dave Walmsley)
  498. Subject: DOS
  499. To: tcp-group@ucsd.edu
  500.  
  501. Lyndon et all.
  502.  
  503. My thoughts when Johan defected ;-), we just need a Winsoc or packet driver
  504. that sits below all the goodies that live on the net. I wish I had the
  505. knowledge and time to get such a project started.
  506.  
  507. >The scary thing is that *all* the application software has already been 
  508. >written. All that's missing is a packet driver that knows how to talk to 
  509. >a TNC and fake out AX25 callsign/SSID MAC addresses as if they were 
  510. >Ethernet MAC addresses.
  511. >
  512. >--lyndon
  513. >
  514.  
  515. Dave
  516. =========================================================================
  517.  
  518.  
  519. Dave VK2XPX, sysop VK2RAP                   ccdrw@cc.newcastle.edu.au
  520.                                             sysop@vk2rap.newcastle.edu.au
  521.                                             vk2xpx@vk2xpx.ampr.org
  522.  
  523. =========================================================================
  524.  
  525. ------------------------------
  526.  
  527. Date: Thu, 7 Jul 94 01:26:16 +0100
  528. From: Adrian Godwin <adrian@fangorn.demon.co.uk>
  529. Subject: Index to the tcp-group mail archives
  530. To: tcp-group@ucsd.edu
  531.  
  532. As I suggested earlier, I've made a first stab at a topical index of
  533. the tcp-group mail archives. It's rather slow work, and the only other
  534. volunteer is looking at using WAIS in the hope of producing a longer-term
  535. solution, so I've only done 1987 so far.
  536.  
  537. This index is on ftp.ucsd.edu as 
  538. hamradio/packet/tcpip/incoming/tcp-group-index.87a.gz
  539.  
  540. I'm holding indexed articles in MH folders, but I didn't want to
  541. upload the entire archive in this form. For the moment I've 
  542. just created a file containing a list of topics and pointers (in
  543. the form of subject // author // date // message ID) to the articles.
  544. This is probably useable as input to a reformatter for a browser
  545. such as WWW, but may be of little use for manual browsing in the
  546. meantime, especially as the 1987 files are simply two simple mail
  547. folders - you have to download them and search for the index entries,
  548. and the lines in the index are rather long.
  549.  
  550. I'd appreciate comments on :
  551.  
  552.   - a more useful format for the index
  553.   - my arbitrary choices of topic title and group
  554.   - the granularity of the topics
  555.   - pretty well anything else relevant
  556.  
  557. By 'topic' I mean the name for a series of threads on related subjects.
  558. By 'group' I mean a series of vaguely related topics. This should be
  559. pretty obvious from the index file.
  560.  
  561. The topic list started out as a bunch of likely topics off the top of
  562. my head and was adapted slightly as I went along. As a result, some
  563. articles are doubly-indexed (I consider this a feature, not a bug) and
  564. some topics are empty (for the moment).
  565.  
  566. Note that I've no intention of setting up a browser for this myself - 
  567. long term, a WWW server on ucsd (and perhaps a WAIS interface) is the aim.
  568.  
  569. -adrian, g7hwn
  570.  
  571. ------------------------------
  572.  
  573. Date: Wed, 6 Jul 94 04:00:56 CST
  574. From: Jack Snodgrass                                   <kf5mg@kf5mg.ampr.org>
  575. Subject: LPD help
  576. To: tcp-group mailling list                            <tcp-group@UCSD.EDU>
  577.  
  578.     I've compiled in the LPD stuff with JNOS, but can't figure out if it
  579. works or how to use it. Has anyone else figured it out? I'd appreciate if
  580. someone who's using LPD with NOS could send me a working printcap example.
  581. I'm using a Canon BJ-200 printer ( IBM ProPrinter compatible ) on LPT1 but 
  582. I'd like to see ANY WORKING /etc/printcap example that defines a printer on
  583. LPT1. Thanks.
  584.  
  585. 73's  de  Jack  -  kf5mg
  586. Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  587. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  588. Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  589.  
  590. ------------------------------
  591.  
  592. Date: Thu, 7 Jul 94 09:52 +1000
  593. From: ANDY JOYCE <A.JOYCE@qut.edu.au>
  594. Subject: PE1CHL Source Code?
  595. To: TCP-Group@ucsd.edu
  596.  
  597.    Hi all,  Im working with some project students here at QUT who will be
  598. using TCP/IP and the FTL0 Pacsat broadcast protocol for use within the TSG
  599. Telemetry Systems Group within the University here. We would like to add some
  600. station control code to the PE1CHL version of NOS that also uses the FTL0
  601. protocol. The problem is that we have been searching high & low for source
  602. code or an Email address to PE1CHL, but we cannot find either? Does anyone
  603. know if source code for PE1CHL-NOS is available and/or a FTP site, or either
  604. a Email address so we can contact PE1CHL direct...
  605.  
  606. Thanks..
  607.  
  608. Andy Joyce VK4KIV
  609.  
  610. AARNet/Internet - A.Joyce@qut.edu.au
  611. AMPRNet/Packet  - vk4kiv@vk4kiv.qut.ampr.org
  612.  
  613. Queensland University of Technology:
  614.  
  615. ------------------------------
  616.  
  617. Date: Wed, 6 Jul 1994 10:05:07 -0600 (MDT)
  618. From: Tim Baggett <wbaggett@NMSU.Edu>
  619. Subject: TCP-Group Digest V94 #140
  620. To: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  621.  
  622. > Karl writes:
  623. >   [Stuff deleted]
  624. > >     I have read guys saying Linux is the way to go and I say bull 
  625. > > pucky! Linux to have ANY speed must live in 8 meg of ram on a 88486-50. 
  626.  
  627. Well Karl, as you know, I just got Linux installed on a 386dx-25mhz, 8 mb 
  628. RAM machine here at school. Its not a Sun SPARC 10, but I can see power 
  629. roaring under the hood already. Actually I'm quite content with the 
  630. speed, so far.
  631.  
  632. > > This translates into a MUCH more expensive computer and I'm not sure you 
  633. > > can boot up in Linux without dos being present. Need to run an experiment.
  634.  
  635. No MS-DOS present at ALL on my Linux machine (YEAH!). Boots right up into 
  636. Linux. Not even the slightest hint of MS-DOS. I wiped that sucker clean 
  637. out when I formatted the hard drive :-)
  638.  
  639. > >     As one tag line says " Are you still using dos? Pity" I say if 
  640. > > you are paying for your software dos is a good deal. So is Windows ver 
  641. > > 3.1 and a host of other software written for dos. From my point of view 
  642. > > going back to UNIX with it's $2,000.00 software is a real BAD idea!!
  643.  
  644. Well, Linux cost me about $20 worth of disks to put it on. Snag it from 
  645. net.tamu.edu.
  646.  
  647. Finally, I found out what your supposed to do with a PC clone (besides 
  648. using it as a door-stop, which people at work tell me) - format the HD 
  649. and install *NIX :-) :-) Linux is just like the big machines, and real 
  650. timesharing! none of this crowbarring it into MS-DOS (Although you did a 
  651. good job of forcing MS-DOS to do it Phil!)
  652.  
  653. 73
  654. Tim
  655.  
  656. ********************************************************************
  657. Tim Baggett, AA5DF                    Electrical Engineering Student
  658.                                       New Mexico State University       
  659. Internet: WBAGGETT@NMSU.EDU     
  660. AMPR: AA5DF@NMSUGW.AMPR.ORG           US Snail: 1805 Rentfrow Apt #1
  661. (When on) AA5DF.AMPR.ORG                        Las Cruces, NM 88001
  662. ********************************************************************
  663.  
  664. ------------------------------
  665.  
  666. Date: Wed, 6 Jul 94 16:21:03 PDT
  667. From: efb@suned1.nswses.navy.mil (Everett F Batey)
  668. Subject: Why not a solid PBBS prog .. or Net.TV ?
  669. To: tcp-group@ucsd.edu
  670.  
  671. Perhaps a look at Broadcast / Multicast Internet television would give
  672. us a model to consider .. Saw it running at ISI last year so .. if we
  673. have a backbone equivalent then we can spread tiled pictures ( a la
  674. CCITT- Gp4 ) or send newsgroups .. //
  675.  
  676. --
  677.  +  efb@suned1.nswses.Navy.MIL  efb@gcpacix.uucp  efb@gcpacix.cotdazr.org +
  678.  +  efb@nosc.mil   WA6CRE    Gold Coast Sun Users   Vta-SB-SLO DECUS  gnu +
  679.  +  Opinions, MINE, NOT Uncle_s | WWW b-news postmaster xntp dns  WAFFLE  +
  680.  
  681. ------------------------------
  682.  
  683. End of TCP-Group Digest V94 #141
  684. ******************************
  685.